1. Field of the Invention
The present invention relates to the field of software integration and, more particularly, to procedure invocation in an integrated computing environment having both compiled an interpreted code segments.
2. Description of the Related Art
Software engineers utilize many different programming languages, each having its own advantages and disadvantages. Categories of programming languages include compiled and interpreted languages. A compiled language requires a compiler program to turn programming code into an executable machine-language binary program. After compiling once, the program can continue to be run from its binary form without compiling again. Compiled languages/programs tend to be faster than interpreted languages, but are often more difficult to program than interpreted languages. Further, once compiled, the compiled program can run only upon a single hardware platform for which compiling occurred, thereby making it difficult to port an compiled program from one platform to another. Examples of compiled languages include C, C++, C#, COBOL, and FORTRAN.
An interpreted language converts programming code into a binary form automatically when the program is run. The binary form is executed by an interpreter designed for the computing device upon which the programming code is to execute. A “pure” interpreted language converts program code to a binary form automatically, each time the program code is executed. Most interpreted code can be easily ported from one computing platform to another because the interpreted code remains constant as different platform-specific interpreters can be used to execute the interpreted code upon each computing platform. Interpreted language can include a great many advantageous services relating to security, error checking, simplicity, and the like. Generally, interpreted languages tend to execute slower than compiled languages. Interpreted languages, however are often easier to program, test, and/or maintain than compiled languages. Examples of pure interpreted languages include BASIC, PERL, PYTHON, and REX.
A Pseudo-code (p-code) language is a type of interpreted language that is somewhat of a hybrid between a compiled language and a pure interpreted language. P-code programming code is not compiled into a machine executable form, but is instead placed in a binary form that requires an interpreter before the code is executable upon a computing device. Unlike “pure” interpreted languages, however, a p-code program does not have to be converted to a binary form each time the program is run. Instead, the first time a p-code program is run, the binary form of the program is saved. The saved form is retrieved and used for each additional execution. That is, a p-code language can convert code entered by a programmer into an intermediate representation, which the interpreter executes. Examples of p-code languages include JAVA, PYTHON, and REXX.
Software developers often desire to integrate code written in a compiled language with code written in an interpreted languages, thereby taking advantages of the strengths of each. For example, a software developer can want to rapidly construct a software application in a secure, platform independent manner using advantages of an interpreted language, like the JAVA programming language. This interpreted language, however, may not support platform dependent features needed for the application. The software developer can also desire to utilize a preexisting application or library written in a compiled language, like the C programming language. Another possibility is that a small portion of time-critical code within the software application can demand the efficiency of a lower-level programming language. Unfortunately, integrating code written in different languages and/or different types of languages can add complications and inefficiencies to the resulting integrated software application that rival the advantages of integrating code in such a manner.
Many interpreted languages provide a standardized interface for integrating “native” code with interpreted code for the interpreted language. Native code is code that has been compiled to processor-specific machine code also referred herein as compiled code. For example, the JAVA programming language provides the Java Native Interface (JNI) that permits code running inside a JAVA VIRTUAL MACHINE to interoperate with applications and libraries written in other programming languages, such as the C and C++ programming language. The standardized interface for interpreted languages, however, contain substantial overhead to assure that safeguards are in place to prevent native programs from having negative side effects upon the interpreted environment. Moreover, most standardized interfaces for native code do not permit these safeguards to be manipulated by developers. As a result, methods called using a native language interface of the interpreted language tend to suffer performance degradations, which often outweigh the advantages of using the interface. For example, the method calls from native code to within a JAVA VIRTUAL MACHINE that use the JNI interface are typically about 20 times slower than calls from one procedure within the JAVA VIRTUAL MACHINE to another.
Conventional integration techniques suggest the use of special wrappers and method specific control blocks as the best way to integrate code. Such techniques make calls between languages an element of predefined design. The wrappers add overhead to every call, thereby reducing efficiency of every wrapper compliant call, which may in itself overbalance the benefits in using multiple languages for an application. Additionally, software developers and maintainers must further learn the specifics of the wrapper, which increases the cost to create and maintain software.
Further, such a technique requires specialized software associated with the wrapper to be loaded and executed upon a hardware platform in which the wrapper-based integrated environment resides. This specialized software is generally written in a platform dependent fashion, limiting the portability of the resulting integrated application. The specialized software can also have an associated cost to a user of the software, which many users may be unwilling to incur.